As application development projects grow larger, packages are becoming both increasingly important and cumbersome. For example, when changes are made to currently existing Advanced Business Application Programming™ (ABAP) software, the implication of such changes are difficult to foresee, which often causes problems in the future. Having an improved package can make the software's blueprint visible, which can make the changes to the software foreseeable and better protected against malicious changes.
FIG. 1 illustrates a prior art package 100. The package 100 is also known as development classes because it represents a group of objects 102, where each object 102 is assigned to a development class. Each development object 102, such as report, global class, data element, and table, is assigned to the package 100. The object 102 contains organizational attributes, such as person responsible, application component, etc., and technical attributes, such as transport layers, software component, etc. The package 100 also includes a package interface 104 to expose the object 102 to those who seek the object 102.
The package 100 is viewed as a capsule whose content is hidden to the outside. Any interaction with the package's content is accomplished through the development objects 102 that are exposed via an interface 104 of the respective package 100. Furthermore, the package 100 determines transport properties of development object 102 contained in it, such as whether the object 102 can be exported from the system, and what are the target systems (using the assignment to a transport layer).
Referring now to FIG. 2, it illustrates nesting 200 of multiple packages 202, 208. As illustrated, a package 208 is nested into another package 202. When nesting 200, the package 208 is visible only within its package 202. This package nesting 200, for example, allows for structuring of packages 202, 208 by placing the development objects 210 needed only for a certain part of the implementation into a separate package 208. The package 202 exposes its own development objects 204 via its interface 206 as well as the objects 210 of the package 208. Those development objects of the package 208 that are not exposed at the package's interface 206 are invisible outside the package 202 and can only be used from within the package 202.
FIG. 3 illustrates a prior art generation mechanism 300. As illustrated, a special query 308 is received from a client. The query generator 310 analyzes the query 308 and then generates appropriate extractors 312-316 for the packages 302-306. The term appropriate refers to having the extractors 312-316 that are specifically adopted to the actual query by the generator 310. Due to package modification restrictions, extractors 312-316 are currently generated into special packages outside the packages 302-306 to be analyzed that do not provide such package modification restrictions. Further, several extractors 312-316 can be generated into the same package or even having various generators 310 sharing the same package. Currently, some packages (e.g., non-transportable) are mingled with generated objects that are often unknown and do not provide a real purpose, which, for example, makes it difficult to analyze where the problems with the generated coding might be. The extractors 312-316 then access the packages 302-306 from independent packages.
Each of the packages 302-306 contains an extractor 1-N 312-316 to extract the information needed for forming the results 320. A query analyzer 318 is used to analyze the data extracted from the packages 302-306 and provides the return results 320 back to the client. The illustrated generation mechanism 300 is an example for ad-hoc queries for business data, and the like.
Although the conventional package mechanism provides increasing flexibility for better structuring of software, and represents an essential tool for ensuring and tracking decoupling of software, further improvements to the existing package mechanism are needed. For example, the conventional package mechanism lacks strategies with regard to handling generation of objects and enhancements to software.